Le 15 février 2022 est sortie la version 2.3 du logiciel de gestion de la relation client Crème CRM (sous licence AGPL-3.0). La précédente version, la 2.2, était sortie quasiment un an auparavant, le 19 janvier 2021.
Pas mal de choses au programme, notamment la possibilité de personnaliser le menu principal, la disponibilité comme un paquet Python classique et une image Docker de démonstration. Les nouveautés sont détaillées dans la suite de la dépêche.
Sommaire
Description du logiciel
Crème CRM est un logiciel de gestion de la relation client, généralement appelé CRM (pour Customer Relationship Management). Il dispose évidemment des fonctionnalités basiques d’un tel logiciel :
- un annuaire, dans lequel on enregistre contacts et sociétés : il peut s’agir de clients, bien sûr, mais aussi de partenaires, prospects, fournisseurs, adhérents, etc. ;
- un calendrier pour gérer ses rendez‐vous, appels téléphoniques, conférences, etc. ; chaque utilisateur peut avoir plusieurs calendriers, publics ou privés ;
- les opportunités d’affaires, gérant tout l’historique des ventes ;
- les actions commerciales, avec leurs objectifs à remplir ;
- les documents (fichiers) et les classeurs.
Crème CRM dispose en outre de nombreux modules optionnels le rendant très polyvalent :
- campagnes de courriels ;
- devis, bons de commande, factures et avoirs ;
- tickets, génération des rapports et graphiques…
L’objectif de Crème CRM est de fournir un logiciel libre de gestion de la relation client pouvant convenir à la plupart des besoins, simples ou complexes. À cet effet, il propose quelques concepts puissants qui se combinent entre eux (entités, relations, filtres, vues, propriétés, blocs), et il est très configurable (bien des problèmes pouvant se résoudre par l’interface de configuration) ; la contrepartie est qu’il faudra sûrement passer quelques minutes dans l’interface de configuration graphique pour avoir quelque chose qui vous convienne vraiment (la configuration par défaut ne pouvant être optimale pour tout le monde). De plus, afin de satisfaire les besoins les plus particuliers, son code est conçu pour être facilement étendu, tel un cadriciel (framework).
Du côté de la technique, Crème CRM est codé notamment avec Python/Django et fonctionne avec les bases de données MySQL, SQLite et PostgreSQL.
Principales nouveautés de la version 2.3
Voici les changements les plus notables de cette version :
Les dépendances
Django 2.2 arrivant en fin de vie en avril 2022, nous sommes passés à Django 3.2, la dernière version LTS.
Notre version de la bibliothèque JavaScript jQuery était franchement ancienne, et une grosse mise à jour a été faite en passant à la version 3.6. Au passage nous avons aussi augmenté la version de notre calendrier FullCalendar qui est désormais la 3.10.
Jusqu’à présent, la minification du JavaScript et du CSS était faite, par défaut, par des logiciels en Java (respectivement Closure et YUICompressor). Il y avait certes moyen de ne pas faire de minification du tout, afin de ne pas avoir à installer Java, mais c’était dommage. Désormais la minification du JavaScript est faite par rJSmin, et celle de la CSS par csscompressor, tous deux codés en Python. Pour le CSS la taille des fichiers finaux est identique, mais la phase de minification est beaucoup plus rapide. Pour le JavaScript, la minification est là aussi très rapide, mais les fichiers finaux sont un peu plus gros qu’avant (installation par défaut: on est passé de 355Kio à 457Kio ; pour information c’est 822Kio sans minification). Les résultats sont suffisamment bons pour l’installation par défaut (et vous pouvez toujours utiliser Closure si vous le souhaitez).
La communication avec le gestionnaire de job, qui permet l’exécution de tâches longues et/ou périodiques, peut (sous Unix) se passer de Redis et plutôt utiliser une socket Unix.
La disponibilité en tant que paquet
Le travail pour faire de Creme un paquet Python classique avait été entamé dans les versions précédentes, mais n’était jusqu’ici pas complet. Lorsque vous déployiez une instance, vos fichiers de configuration (ainsi que votre propre code dans le cas où vous vouliez avoir vos modules personnalisés) traînaient encore au milieu du code de Creme (il y avait en fait moyen de bidouiller pour éviter ça, mais ce n’était ni documenté ni tout à fait fonctionnel). Ce n’est, désormais, plus le cas, vos fichiers sont complètement séparés, et Creme peut être installé comme un paquet Python comme les autres, typiquement dans un virtualenv.
Ainsi nous avons rendu disponible Creme sur PyPI, le dépôt de paquets Python bien connu, ce qui permet de l’installer avec un simple pip install creme-crm
(ce qui est un poil moins rebutant que devoir faire un git clone
).
Le menu principal configurable
Il est maintenant possible de modifier graphiquement le menu principal : on peut rajouter ou enlever des conteneurs et des entrées. Avant il fallait forcément le faire via du code, ce qui limitait à des utilisateurs plus avancés, et rendait les modifications bien plus pénibles à déployer en production.
Plus de détails ici.
La configuration de champs comme obligatoires
Les champs optionnels (c’est-à-dire qu’on peut laisser vides dans les formulaires) peuvent être configurés comme obligatoires, comme on pouvait déjà le faire avec les champs personnalisés.
Plus de détails ici.
Quelques autres améliorations en vrac
- Les formulaires personnalisés peuvent maintenant être spécifiques à un rôle utilisateur.
- L’historique a été amélioré : les valeurs des textes longs, des champs Many-To-Many (choix multiples) sont désormais enregistrés, les modifications des champs personnalisés sont enfin historisés.
- La recherche globale peut désormais se faire dans les champs personnalisés (de type texte uniquement).
- Les types de Propriétés (un peu l’équivalent de tags dans Creme) peuvent désormais être désactivés ; ils ne sont alors plus proposés dans les formulaires.
- Les alertes et les Todos validés peuvent être affichés (ils étaient forcément cachés jusqu’à présent).
- L’interface de configuration des blocs des fiches a été améliorée ; elle est plus intuitive, compacte, et des descriptions s’affichent pour chaque bloc, ce qui amène une meilleure « découvrabilité » de leurs fonctions.
L’image Docker de démo
Si notre démo en ligne a l’avantage d’être accessible en un clic, elle a quelques inconvénients. Nous sommes obligés de rendre inaccessible l’interface de configuration (pour éviter que des configurations « cassées » par les uns soient utilisées par les autres), il n’est pas conseillé d’y mettre des données sensibles (car visibles par les autres) etc.
Bien que l’installation ne soit pas très complexe (surtout avec la disponibilité sur PyPI), nous proposons aussi désormais une image Docker de démo qui permettra à ceux qui le désirent de se faire rapidement une idée des capacités du logiciel.
Cette image a été conçue comme plutôt légère, à des fins de démonstration :
- elle utilise SQLite, pour ne pas dépendre d’une image pour PostGreSQL/MySQL.
- l’absence par défaut de Java dans la nouvelle configuration par défaut nous a permis d’alléger l’image (il y aurait sûrement encore à gratter).
- nous avons utilisé la nouvelle possibilité d’utiliser des sockets Unix plutôt que Redis pour ne pas dépendre d’une image pour ce dernier.
Le mot de la fin
Je n’en avais jamais parlé dans mes dépêches, mais nous avons aussi une chaîne Youtube avec des didacticiels.
Que nous prépare la prochaine version ? Au moins le passage à Python 3.7 comme version minimale, et une refonte des imports de données depuis les e-mails. La feuille de route n’est pas encore totalement établie, mais peut-être que vos propres contributions (en code ou en argent) en feront partie.
Aller plus loin
- Site officiel (326 clics)
- Démo en ligne (245 clics)
- Le dépôt de source (158 clics)
# image docker
Posté par steph1978 . Évalué à 2.
C'est cool que vous ayez travaillé à la réduction des dépendances et à la construction d'une image de démo. Elle est très proche de ce que j'utilise pour mon petit périmètre, je vais me mettre à la migration de ma 2.2.
Au doigt mouillé, quel est votre niveau de confiance quant à d'éventuelles régressions entre la 2.2 et la 2.3 (je vois une 2.3.1) ?
[^] # Re: image docker
Posté par GuieA_7 (site web personnel) . Évalué à 4.
Comme d'habitude la version 2.2 sera encore maintenue jusqu'à la sortie, l'année prochaine, de la version 2.4. Cela vous laisse donc 1 an pour faire tranquillement votre migration. Vous pouvez donc attendre quelques versions de correctifs si ça peut vous rassurer.
On sort généralement une version corrective par mois ; j'ai préféré avancer la sortie de 2.3.1 car il y avait des petits soucis avec l'installation du paquet (donc pas de régression au cours du fonctionnement de l'application, mais des problèmes --contournables à la main—que je trouvais dommage, surtout pour des gens qui feront une première installation).
Je suis globalement confiant sur les régressions ; vous travaillons pour nos nouveaux clients avec la version 2.3 depuis qu'elle est en RC1 (ce qui nous a permis de corriger quelques bugs mineurs).
Et en général les bugs sont corrigés très rapidement après qu'ils sont rapportés ; si basculer sur une branche GIT ne vous fait pas peur, vous pouvez avoir votre version corrigée en 1 poignée de jours (par exemple la branche v2.3.2 sera disponible bien avant d'être fusionnée dans v2.3 lors la release officielle de la version 2.3.2).
Évidemment le mieux est de tester votre workflow sur la 2.3 avant de l'utiliser en production, afin de nous remonter les éventuels problèmes (il n'y a pas de secret, parfois mêmes des bugs triviaux passent au travers des mailles du filet pendant des mois parce que personne ne se sert d'une fonctionnalité d'une certaine façon, ou ne prend le temps de faire un rapport de bug plutôt que de contourner le souci).
J'espère que tout ira bien avec votre migration !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.